Introduction to Letter of Credit

Sometimes, due to non-availability of credit line or any other business reasons, advising or nominated bank adds confirmation to an export LC only for a part amount. This means that the amount confirmed only needs to be updated in credit limit of the issuing bank, not the full amount of the LC. This could be either a fixed amount or a percentage of the LC amount. 

In an unconfirmed LC, limit line defaults to the info line unless and otherwise defined in LIMIT.PARAMETER. Similarly, in the case of confirmed LC the limit line goes as per the definition in the LIMIT.PARAMETER. However, with partial confirmation, an option is available with the user to choose to hit the info line and not for the unconfirmed portion of the LC. This is setup in LC.PARAMETERS by setting the Unconfirmed Limit field to Yes or No.

When an export LC is partially confirmed, the limit line is split and one is set against the confirmed portion and the other against the unconfirmed. When this information limit line is considered redundant in a partially confirmed LC, it is suppressed by setting this field to No.  When set to Yes, the information limit line appears. Suppression of information limit line is done only if the LC is partially confirmed.

This field indicates the tolerance that can be ignored while calculating the limit amount minus provision amount. 

• When 100% provision is taken on a foreign currency LC, the limit when calculated in limit currency may work out to 100.01% or 99.78% depending on the exchange rate. 
• An input of a tolerance figure in this field is by the system as a limit to be ignored and when the difference falls within the parameter value it is ignored.

The below advice and report related fields are defined in LC.PARAMETERS to determine how many number of days prior to an event a message should be sent or reported:

Delivery process in LETTER.OF.CREDIT and DRAWINGS module enables to produce additional messages or advices other than standard ones provided by the system. Through the soft-delivery mechanism, the user can attach any additional message and send it via delivery.  For a soft delivery option, the Backward Delivery field to be set to No. The Lc Class Type and Eb Class No multi value fields are necessary for soft delivery set-up. It is recommended to use the MB data for the initial build.

If Takeover Process field is set to Yes, then no delivery message is produced. This can be used during take over from existing system. A customer record can be created for the bank using the system by input in the Cust By Order field. Information in this field is used in Swift messages Tag 50 – Ordering Cust. After the introduction of soft delivery, certain existing fields are not used. For export LC, When the Del With No Discrep field is set to Yes, MT 750 and 1750 messages are produced whether drawings are discrepant or not. When set to No, MT 750 message is produced only if drawings have discrepancies.

Transaction codes are used in STMT.ENTRY and CATEG.ENTRY for narrating the underlying transactions affecting accounts and PL heads are attached to the LC.PARAMETERS as below:

Internal accounts in local currency should be opened using these category codes. The system opens in other currencies, when needed. If the provision is kept at the customer (account) level, then Internal account opened using the category code indicated in Pro Category field is used as credit provision account. Currency of this account is that of debit provision account.

The Pay Subdivision field identifies the subdivision to be used whenever an internal account number is generated by the system for accounting entries related to LC payments (it is the equivalent of a G/L sub-ledger number).  If 1 is indicated here, and 16505 category code is proposed to be used for internal account, the system uses USD165050001 for USD provision and GBP165050001 for GBP provision.

This field in LC.PARAMETERS application defines, if the provision is to be calculated for LC or liability amount at parameter level.

• This field in the LETTER.OF.CREDIT application defaults the value defined at the parameter level. If the user wants to modify the defaulted value, it can be done at LC contract level. Temenos Transact calculates and collects provision from customer based on these settings.
• Validations are provided with error message.
• When the user selects a value in Prov Calc Base field, but the Provision field is not set to Yes in LC application, the system displays an error message to set the Provision field to Yes.
  When the user opens an Import LC for USD 10000 with 50 % cash margin and the provision calculation base is LC amount, the system calculates USD 5000 as cash margin. If the user has given 10% credit tolerance and the calculation base is the liability amount, then the amount of provision calculated by using the same example works out to USD 5500. LC value is 10000 plus 10% tolerance, which is 1000. Margin is calculated at 50 % on 11000, which works out to 5500.

Prov Netting

The user can net the proportionate cash margin released with the drawings amount and debit the balance amount from the drawdown account when drawings are initiated using this field.

• The value defined in LC.PARAMETERS is defaulted and the user can amend the defaulted value
• The user can amend the defaulted value.
• This field assumes significance only if provision is collected in the underlying LC. This is a no change field.
• Drawings payment entries are netted with the proportionate amount of cash margin released only when the drawings currency and credit provision account currency are the same.

In LC.PARAMETERS, the multi value field Synd Chg Code allows the user to enter a valid FT.COMMISSION.TYPE or FT.CHARGE.TYPE ID and these specific charges work in conjunction with the Syndicate Charge field in LC. When Syndicate Charge is set to Yes, the system checks that the respective charge code is specified in the Synd Chg Code field of LC.PARAMETERS.

An initial setup is done at the parameter level, to enable the settlement of Import or export drawings through PAYMENT.ORDER. The Po Wash Categ and Po Product fields under LC.PARAMETERS has to be defined for linking the PAYMENT.ORDER (PO) application to import or export drawings. When a settlement is routed through PAYMENT.ORDER, the system credits or debits a wash account created in the respective currency. To define the category for this wash account, Po Wash Categ field is used. When these fields are defined at parameter, the system allows the integration of DRAWINGS and PAYMENT.ORDER module. However, the user can choose at the transaction level, the option to settle a particular drawing via PAYMENT.ORDER.

The Po Wash Categ lists all the internal account category codes. This field identifies the category code of the internal wash account to which the proceeds under the LC drawings is taken for settlement, when the payment method is N in DRAWINGS application.

The Po Product field lists the record ID of a valid PAYMENT.ORDER.PRODUCT. Payment features that are specific to DRAWINGS application is defined in PAYMENT.ORDER.PRODUCT at the parameter level for the application to refer, when a payment is initiated. The PAYMENT.ORDER.PRODUCT maps the data among the PAYMENT.ORDER, DRAWINGS and third party or integrated payment application. When the linking of POA with DRAWINGS is not defined at the parameter level, the existing feature continues to settle the payment within the DRAWINGS application.

PAYMENT.ORDER.PRODUCT defines payment features that are specific to LC settlement with values such as Allowed, Optional and Mandatory. Besides, it defines the mapping rule and conditions that specify how the requests from the payment order is routed to the corresponding payment system. Based on this definition in the LC.PARAMETER, the Payment Order product field in the PAYMENT.ORDER application defaults with respective input when PAYMENT.ORDER record is created at the time of settlement of the LC from DRAWINGS module.

The below screenshot defines a LC.PARAMETERS record for linking PO application:

The below screenshot shows a record created in PAYMENT.ORDER.PRODUCT:

The Switch Limit field controls the change of limit lines from customer-to-bank or bank-to- customer in DRAWINGS. The allowed values are:

• Yes - The Risk Party field allows for user input.
• No - The Risk Party field behaves as a system populated field and the value defaults from Risk Party field of the LC application.
• NULL - Default value

This Switch Limit field becomes a no-change field after authorization if the value is YES or NO.

This file is used to set the type of LC and the way Temenos Transact treats the transaction through its various phases from opening, drawing, to maturity. It defines and describes the LC (and collection) types required in the system, and the setting up of  the default category code for each type. The characteristics of each LC and collection type are recorded in this file.

Generally, banks have minimum LC.TYPES, such as, one for any pre-advices, actual advices and for adding confirmations. Depending on each pay-type, further LC.TYPES can be added. The records provided with the Temenos Transact installation should be treated as a starting point and each one must be reviewed or amended, and new ones entered according to the type of trade finance business. The code defined in the Category Code field is defaulted, when the category code is not entered as part of LC input data. If any LC transactions existing under this LC.TYPES are in the live or unauthorised file, this field cannot be modified as that would lead to conflict in ASSET.TYPE in consolidated CRF entries.

From the Import/Export field, the user can select either I or E, where:

• I – Import (issuance)
• E – Export (advising or confirming)

Based on the user selection, the process treats the LC as import or export. Temenos Transact uses this setting to dynamically configure which fields are available and mandatory when opening or amending an LC. This field cannot be modified once LC transactions under this LC type has been entered. For DRAWINGS, the LC.TYPES is taken from the parent LC LETTER.OF.CREDIT record.

The LC.TYPES record defines whether the transaction is:

• Import or export
• Transferable LC or non transferable
• Standby LC
• Confirmed or unconfirmed
• Back to back and with what type import back to back LC is generated
• Documentary collection
• Clean collection
• Clean credit
• Different pay types, that is, payment method - by payment, acceptance, negotiation, direct credit, mixed payment or deferred payment.
• Enabling the duplicate check
• Define a group of message formats
• Add exceptions to field defaulting rules

Apart from defining the above characteristics of LC in LC.TYPES, there are few system-populated fields, which provide,

• Information on the number of pre-advised LCs outstanding for an LC.TYPE (pre advised).
• Count of the number of LCs opened for an LC.TYPE (opened)
• Count of the number of LCs which have expired but have not yet been closed in the system for an LC.TYPE (expired not closed)

In conjunction with the LC.TYPES key, Temenos Transact uses an operation type to decide the event, accounting and charges to be applied. The codes are entered both in the Operation field in the LETTER.OF.CREDIT transaction and LC.TYPES, as part of the key to the charges conditions file LC.TXN.TYPE.CONDITION. Similarly, the DRAWINGS transaction uses the Drawings Type after the LC.TYPES to find a matching LC.TXN.TYPE.CONDITION.

The below codes are used:

LC.TYPES parameter table is essential in building the foundation of the trade finance set-up to accommodate range of transactions from clean collections to complex documentary credits.

The following are the different types of LC:

The Classification field allows the user to categorise the LC.TYPES based on the bank’s business requirements. Following are the available values for the Classification field,

• Leasing
• Domestic
• International

If required, banks can add a new type of classification value using EB.LOOKUP record.

While creating LC (Import), the user has to enter lengthy document descriptions. These descriptions are used frequently for most of the transactions generated every day. To assist and speed up the processing, Temenos Transact has LC.ADVICE.TEXT, which enables the user to record the standard document details required for different types of LC under a coded ID. The values are entered in the Document Code multi-value field in LC and DRAWINGS to get the document text defaulted in the transaction.

Record ID of LC.ADVICE.TEXT accepts the following formats:

• Customer ID-Inco Terms-Mode of Shipment
• Inco Terms-Mode of Shipment
• Customer ID
• Customer ID-Free Text
• Free Text

LC.CLAUSES

In addition to document descriptions, trade finance also requires the input of many lengthy additional clause. Standard LC clauses are held in this table, which holds static information for construction of LC transactions within Temenos Transact. They are included in a LC or collection by the use of a code, avoiding the need for retyping.

The codes defined in LC.CLAUSES is invoked in the Clauses Text multi-value field in LC and DRAWINGS based on the record ID. They are then expanded into the actual text, which can be modified for the contract.

It is the text which is stored and any change in the record, the text that was valid at the time of data entry is preserved.

Record ID of LC.CLAUSES accepts the following formats:

• Customer ID-Inco Terms-Mode of Shipment
• Inco Terms-Mode of Shipment
• Customer ID
• Customer ID-Free Text
• Free Text

 

The core feature of validating duplicate input is now available in LETTER.OF.CREDIT. Set of rules for checking whether an LC transaction is likely to be a duplicate of another similar transaction can be defined in EB.DUPLICATE.TYPE. The ID of this record is alpha-numeric. For example, LCEXPLC is used to check for duplicates in export LC.

The application for which a duplicate check is intended should be indicated in the Application field in EB.DUPLICATE.TYPE. The values that are to be compared for determining if the transaction is duplicate, should be indicated in multi-value field Fields. This can be a user-defined field or a user-defined calculated value (field type I) on STANDARD.SELECTION. When Lc Currency and Lc Amount fields are indicated, a transaction is termed as duplicate, if its currency and amount are the same as that of another transaction.

Once the EB.DUPLICATE.TYPE is defined, the record has to be attached to the respective LC.TYPES appropriately. The Duplicate Check field in LC.TYPES accepts a valid EB.DUPLICATE.TYPE and based on the definitions to be validated, the overrides are raised when the transaction is input.

One or more records of EB.DUPLICATE.TYPE can be attached to required LC.TYPES records. When a LC of the chosen type is entered, subsequent transactions for possible duplicates can be identified. The ID of EB.DUPLICATE depends on the field defined in EB.DUPLICATE.TYPE file. When only one field is defined in the EB.DUPLICATE.TYPE file, the key is composed of that one field. When more than one field is defined, the key is composed of the number of fields defined, joined together with asterisks (*).

Any contract that matches this key while it is held on file causes a possible duplicate override, and are added to the Trans Ref field. For example, GBP*11000.00. When the currency and amount have been selected as above, when the next LC is entered, the system checks EB.DUPLICATE for similar ID, and if present, generates override and when approved, records details of that transaction also in EB.DUPLICATE under the same record. The record is deleted from the EB.DUPLICATE file based on the number of days defined in the Purge Days field of EB.DUPLICATE.TYPE file.

The trade finance application makes extensive use of short codes (such as O for open) to enable fast and accurate input. However, these codes are not understood if referred elsewhere. When customer advice is printed on customer confirmations. The LC.ENRICHMENT application holds longer descriptions for these codes and abbreviations giving the opportunity to expand the meaning of each of these codes into the user's own terms.

The response Y to certain fields such as, Revocable (Y/N) allows the user to create a transaction more speedily. However, the text required for advices needs to be expanded to 'This LC is Revocable'. The file is fully multi-lingual. A single code may have different meanings when used in different places in the trade finance application. Each place where a code may be used is identified in the LC.ENRICHMENT application.

The screenshot below shows the texts substituted for Y under several circumstances:

In the above screenshot, the code Y when used in the Revocable field in LETTER.OF.CREDIT means revocable, but when used in the Part Shipments field it means part-shipments allowed.

BASIC.INTEREST table allows various frequently used floating rates. For example, base rate, prime rate, overnight rate, etc. It has to be defined separately for each currency and stored in a central place where they can be accessed by Temenos Transact applications as required. Prime records with the same interest conditions can be linked directly to a basic interest ID in this table, rather than defining the interest rate details in each transaction record.

When a rate change takes place, the user has to update the basic interest rate IDs defined in this table with the new rate(s) and the date on which it is to become effective. This is then automatically update all the transaction records, which are tied to each Interest ID. A description of each rate is held in the BASIC.RATE.TEXT table to allow the user to easily identify each one of the basic interest rate table ID's. For this reason, a description is not included in the input parameters of this table. The BASIC.RATE.TEXT table of descriptions must be defined prior to creating this table.

E.B.S. provides a PERIODIC.INTEREST rate table to cater for transactions where the interest rate conditions may change on a pre-defined periodic basis, for example, LIBOR, and also according to the current balance on the prime record. The linking of prime record to a basic interest rate or a periodic rate ID depends on the conditions existing for various products within the bank.

BASIC.RATE.TEXT table defines descriptions of the basic interest rate table IDs to enable the user to identify each one of them easily. Each description must be defined prior to creating rate records for the corresponding ID in the BASIC.INTEREST rate table and is used as the enrichment to the corresponding ID when it is displayed or printed during Temenos Transact processing. Up to 999 descriptions can be defined.

PERIODIC.INTEREST is used by applications such as foreign exchange to default LIBOR types of rates on forward contracts. It uses  interest revaluation method or the loans and deposits applications to perform automatic rollover. Rates vary depending on the length of time and for bid and offer purposes. This table can be automatically updated or interfaced daily with an external feed, like reuters, or maintained manually by the user.  PERIODIC.INTEREST records are generated daily by the system. These periods can be defined in either months or days. For example, 1 month, 2 months, 3 months, 6 months, etc. or 7 days, 15 days, 30 days, etc.

This table is used for discounted drawings using tiered system of rate calculation:

In LD contracts, where the Int Rate Type is set to PERIODIC.AUTOMATIC, on the R (rate revision) schedule dates, the PERIODIC.INTEREST table is referred to, for the interest rate from the appropriate key (record).

Changes can be made to keys which were created before current date, and contracts, which have accessed these keys, are updated with the changes, provided the R schedules were not prior to any principal or interest movements on the contract. Whenever a back-valued key in PERIODIC.INTEREST is changed, the ID of such key is stored in an internal file called PERIODIC.RATE.CHANGE.

Interest day basis is defaulted to transaction records as per the currency used. However, it can be modified at contract level. Choices are available in LC application to indicate the interest day basis. This is useful while discounting usance drawing to calculate the amount of discount. When charges are collected in advance, but proposed to be amortised over the life of an LC, the basis for amortising is decided by this choice. This is defaulted from CURRENCY table, but can be changed by the user.

The following choices available for interest day basis at LC level:

To support the 252-day interest basis (specific to Brazilian market), two-interest day basis, W and W1 are introduced.

• W – 252/252: The numerator represents the number of business days between the start and end dates of the contract.
• W1 – 252/252: The number of days in the numerator represents the number of business days between the start and end days of the contract. If the number of business days is less than 21 days in a month, then the number of business days in a month is considered as 21. If the number of business days is more than 21, system accrues only until the 21st day.

In the DRAWINGS application, the user can define the type of rounding that should take place while debiting or crediting the customer’s account using the Round Rule field. This is a no change field. The value entered in this field overrides the condition defined at the product level, that is, in LC.PARAMETERS.

This rounding rule is already predefined in EB.ROUNDING.RULE. Natural, Round up, Round down, Tax Up, Tax down or None are options already available in EB.ROUNDING.RULE.

The trade finance application allows to set up charges either at,

• The time of LC issuance or advising
• Any time later
• The time of LC payment or negotiation (or after wards as long as the record is still available for drawing)

For certain types of LCs it is possible to take additional charges until they mature. The types of charges or commission has to be defined in FT.COMMISSION.TYPE and other related LC charge tables as shown in the below flow chart:

The links between the various files making up the condition group structure for LC charges and commissions are shown above. The charges and commission applies to the contract in the below flow:

• Details in the LC.CUSTOMER.CONDITION application is applied in the LC contract and works like LC.GROUP.CONDITION (this is specific to a single customer rather than a group of customers).
• Details in the LC.GROUP.CONDITION application is applied in the LC contract in the absence of LC.CUSTOMER.CONDITION.
• Details in the LC.TXN.TYPE.CONDITION application (default charges) is applied in the LC contract in the absence of LC.CUSTOMER.CONDITION and LC.GROUP.CONDITION.
• Details in the application FT.COMMISSION.TYPE is applied in the LC contract in the absence of LC.TXN.TYPE.CONDITION, LC.CUSTOMER.CONDITION and LC.GROUP.CONDITION.

FT.COMMISSION.TYPE

FT.COMMISSION.TYPE table defines the conditions relating to all types of commission used in applications. Each commission type can be defined as a flat amount or percentages can be defined for different bands or levels or flat calculation. Minimum and maximum commissions can be specified for each band or level. Regardless of the percentages set and the transaction value, the bank has to guarantee a minimum commission receipt. The Overall Min Amt field is used to set the minimum commission to be collected. A maximum can also be set, if required, in Overall Max Amt field. Commissions in local currency must be entered and special foreign currency commissions can also be defined if required. It is possible to accrue or amortise the charges and commissions over a period, by suitably defining in FT.COMMISSION.TYPE.

The entire commission may not apply depending on whether the ordering customer is resident or non-resident within certain countries. Additionally, FT.COMMISSION.TYPES can be linked to allow different commission structures, tax codes to be applied depending on the residence of the ordering customer. For example, commissions can be defined for EEC and NON-EEC resident customers.

Minimum Period

This field defines the minimum number of months, which comprise the smallest allowable charging period, used in conjunction with the charge period defined. This can be defined as monthly, quarterly, half-yearly, nine-monthly, annually, or bi-annually.  The contract period is divided into a number of charging periods as defined in Charge Period. This is then compared against the Minimum Period. If the minimum period yields a large value, this is used to calculate the final chargeable amount. For LCs charges or commission are collected based on the LC period.

Charge Period

This field defines the number of months that constitute a charging period. In the above FT.COMMISSION.TYPE case, if the contract is for 6 months, it consists of six charge periods, and hence six times charges defined is taken.

It is possible to collect charges at one exchange rate and the document amount at a different exchange rate. It is also possible to use different accounts for collection of charges. Flexibility to take charges immediately on an acceptance or deferred payment drawing instead of waiting until maturity is available.

The currency codes specified in this table, in association with the percentage or the amount of charges are always refer to the currency of the transfer, that is, the debit currency for the inward payments and the credit currency for all other types of payment. As a minimum, the local currency must be specified and any currency, which has not been defined is then default to these conditions and create the appropriate equivalent amount using the rates held on the currency file.

Charges can be collected multiple times before the contract is moved to history. A charge may be made periodically applied or due. For example, monthly, quarterly, etc. This field determines the length of time for which the commission type record applies. The period of the contract is split into the number of periods defined in this field to calculate the total commission amount.  The input in this field is shown as 1, 3, 6, 9, 12 or 24 indicating monthly, quarterly, half-yearly, nine-monthly, yearly or bi-annually. 

A contract lasting one year, with charge period set to 3, would incur four times the defined commission amount, since the period has been defined as quarterly.  The corresponding Minimum Period field can be used to specify the minimum number of periods to be considered.

Transaction codes for accounting entries are specified through LC.PARAMTERS and FT.COMMISSION.TYPE.

PERIODIC.COMMISSION

Banks normally collect commission for the issuance of LC and for usance drawings. Trade finance module supports calculation and collection of commission based on the tenure of the contract. The tenure-based commission can be collected either upfront or on a predefined frequency. An option to collect or claim the commission is available. The system supports fixed, band and level method of calculation of commission.

The following tables and fields cater to this functionality. The PERIODIC.COMMISSION table defines the period bands of the commission, which links the FT.COMMISSION.TYPE records created for amount bands.

The steps below are defined for a periodic commission:

1. Define FT.COMMISSION.TYPE records for amount band for each period. Maximum and/or minimum amounts is not defined.
2. Define the period bands in the PERIODIC.COMMISSION table attaching the FT.COMMISSION.TYPE record IDs for the respective bands.
3. Create another FT.COMMISSION.TYPE record with the same ID as that of PERIODIC.COMMISSION. 
4. Attach transaction codes, category, minimum and maximum commission amount, tax code, etc. In the Charge Routine field, define the routine as @PERIODIC.COMM.TYPE.

LC.TXN.TYPE.CONDITION (Default Trade Finance Charges)

The LC.TXN.TYPE.CONDITION table is used to define default charges for trade finance products. Each input into the LC system has a set of default charges in this file set up. The default mechanism works by defining in this file, a record corresponding to each type of LC (LC.TYPE), together with the operations that can be performed. 

Charges are defined for each product (as defined in the LC.TYPES application), for each operation on those products (such as pre-advising, opening and amending the LC, etc.), and for each drawing and type of drawing made under an LC product. The key to an LC.TXN.TYPE.CONDITION record is the LC.TYPES key, followed by either the Operation for LETTER.OF.CREDIT or the Drawing Type for DRAWINGS.

Whenever a transaction is entered through the LETTER.OF.CREDIT (including documentary collections) or DRAWINGS applications, a key is built up of, the current LC.TYPE, the current Operation (for LCs), or the Drawing Type (for drawings). This key is then used to retrieve a record from the LC.TXN.TYPE.CONDITION file in order to set up all the default charges for the current transaction. These settings are used for general customers.

To amend the default charges for special clients or those belonging to a pre-defined group, the below condition group files should be setup:

Table	Description
LC.GEN.CONDITION	The general conditions
LC.GROUP.CONDITION	The group conditions

These impact the file CUSTOMER.CHARGE, where the effect of these is seen and additional changes are made. Periodic commission can be defaulted from LC.TXN.TYPE.CONDITION. For LCs, based on operation defined (O, A, P), the commission code is defaulted at the contract level. For drawings, based on drawing type defined (AC, DP), the commission code is defaulted at the contract level.

LC.GROUP.CONDITION and LC.GEN.CONDITION

Temenos Transact can default charges directly on to a LC transaction using LC.TXN.TYPE.CONDITION. The defaulted charge is not based on the customer but the LC type and operation. This structure is ideal for the use of standard tariffs, but in a bank, customers are given benefit in the form of preferential tariff.

To amend the default charges for special clients or those belonging to a pre-defined group the condition group files are setup in the below order: 

Table	Description
CONDITION.PRIORITY	The criteria used and their order of priority for grouping the customers.
LC.GEN.CONDITION	The general conditions – assign a general code and attributes based on the selection criteria set at CONDITION.PRIORITY table to define a group of customers.
LC.GROUP.CONDITION	The group conditions – define the preferential tariffs for that group of customers.

Temenos Transact allows the user to create groups of customers for the defaulting of non-standard tariffs. The CONDITION.PRIORITY file is set at implementation stage and determines what Temenos Transact looks at, to assign a customer to a particular condition group.  The determinants are chosen based on trade finance business needs of the bank hence; it varies from the other CONDITION.PRIORITY files.

LC.GEN.CONDITION

The LC.GEN.CONDITION application defines default general conditions for trade finance transactions. The conditions are specified in the related application LC.GROUP.CONDITION. The purpose of this table is to assign a general code and attributes based on the selection criteria set at CONDITION.PRIORITY table to define a group of customers. Groups can be determined based on customer details such as residence, target, sector or any other customer attribute as per bank's policy.

The criteria used and their order of priority are specified in the CONDITION.PRIORITY application.  A maximum of four priority conditions can be set. These are defaulted in LC.GEN.CONDITION and cannot be changed. The ID of the LC.GEN.CONDITION is referenced in other applications in Temenos Transact.

Charges applicable to a bank customer can be viewed in CUSTOMER.CHARGE application. It is also possible to effect change in any other group at this level. The record ID is a two digit numeric code. A 100 records can be created starting from 00 to 99.

LC.GROUP.CONDITION

The LC.GROUP.CONDITION application defines special conditions applicable to specific groups of customers or individual customers and overrides the normal conditions used by the trade finance application. The ID of the record must be an existing record on the LC.GEN.CONDITION file, if the conditions are for a group of customers. An individual customer is specified by using the ID format <C-customer number>. For example, C-100014 is used to specify an individual charge regime for customer 100014.

The special conditions that apply are divided into four categories:

• Exchange spread – The CURRENCY table contains the conditions applicable to the exchange spread to be taken on transactions involving conversion of currencies.
• Commissions – The FT.COMMISSION.TYPE table contains the standard conditions applicable to all types of commissions that is used in the LETTER.OF.CREDIT application.
• Charges – The FT.CHARGE.TYPE table contains the standard conditions applicable to all types of charges that is applied in the LETTER.OF.CREDIT application.
• Value Date – The transaction type condition LC.GROUP.CONDITION table contains standard customer value date conditions, according to each Transaction Type existing in the LETTER.OF.CREDIT application.

This file also allows the user to indicate if the charges have to be booked as a separate entry. If the charges related fields are left blank, then the default is taken from the Transaction Type and CURRENCY files. In the case of commissions and charges it is possible to define maximum and minimum amounts, together with a discount or premium, at an individual customer level or for a group of customers. This overrules any maximum and minimum amounts specified in the generic commission and charges records.

The following fields of the LC.GROUP.CONDITION application define the special conditions applicable to specific groups of customers or to individual customers. The value in the below fields specifies:

Field	Description
Comm Maximum Amt and Chg Maximum Amt	The maximum amounts to be applied on transfers to which this commission or charge applies.
Comm Minimum Amt and Chg Minimum Amt	The minimum amounts to be applied on transfers to which this commission or charge applies.
Comm Discount Amt and Chg Discount Amt	The amounts to be deducted from the commission or charge amounts calculated.
Comm Premium Amt and Chg Premium Amt	The amounts to be added to the commission or charge amount calculated.

Special pricing related to periodic commission is defined in LC.GROUP.CONDITION for a specific customer or a group of customers.

Customer Float and Payment Type

The Payment Type and Customer Float fields are optional.

• When the Customer Float field is set for a specific customer, the system updates the value date when the drawings transaction is settled.
• The Payment Type field is used to define whether conversion is involved in the transaction, in order to determine if a different value date condition is to be applied.

LC.CUSTOMER.CONDITION

LC.CUSTOMER.CONDITION can also be used to store information with ID as Customer ID. This table has additional facilities to indicate the provision related information in Provis Acct, Prov Percent, Lc Type and Credit Prov Acc fields. Provision percentage can be indicated LC.TYPE wise or as common percentage for all types by indicating DEFAULT in LC.TYPE field. Accounts, if entered, must belong to the same customer and currency.

For a customer with a standard provision account and percentage, the bank can setup the LC.CUSTOMER.CONDITION file with defaults for the provision account or percentage by LC type. Trade finance module provides for a refund or release of the provision at the time of settlement or as required at any time earlier. The provision can be collected from the customer’s account in any currency. The Provision Rate field displays the mid-rate between the LC currency and the provision credit account currency.

LC.ADVICE.TEXT

This section explains the various other user maintained tables that need to be set for operation of the LC and related modules.

Delivery message to the customers for debit or credit of his account, broker for confirmation of trade and depository for completion of settlement of the trade are generated.

Accounting entries are generated on the authorised transactions.

The limit system is designed to monitor the availability and utilisation of limits. Customer limits are monitored in real-time. Back end reports are used to monitor limits for commodities, countries, country groups and currencies. The system caters to  defining both simple and complex limits. LC can be issued after setting up of limits and collateral.

Transactions can be done without creating limits. Temenos Transact creates a limit record for the customer for the relevant limit product automatically on authorisation of the LC contract, in the absence of the limit reference with notification message.

Separate category codes are used judiciously to indicate different types of LCs and collection instruments from reporting angle. Care should be taken when defining additional sub-classifications, that sufficient detail is not available to provide the required breakdown.

LC and DRAWINGS applications use hard coded category range 23000-23999. Each type of LC (and collection) can be defined with a default category code. These codes are used to reflect various LC and collection type in line with the reporting requirement like LC import sight, LC export sight confirmed LC, etc. Further, P/L category code for collecting and writing off charges, commission and internal provision account, category codes used are indicated in LC.PARAMETERS. Default internal accounts in local currency can be opened using the category codes as defined. Category codes between 10000 and 19999 can be used.

ACCOUNT.CLASS records are required for automatic debit or credit by the system. Temenos Transact opens an account in the local currency in the internal category mentioned in ACCOUNT.CLASS. Even if present business does not warrant such setup, it is better to create them. They can be used only if needed. Duplications of category and sector code combined are not allowed within one entry on the ACCOUNT.CLASS table.

There is no standard rule or order for defaulting settlement accounts in LC application. If account numbers are entered for opener, beneficiary and advising bank, then they are defaulted while collecting charges. They are also defaulted in DRAWINGS application.

CURRENCY table contains all details of each individual currency. For example currency name, number of decimal places together with other information such as the buy and sell rates.

The markets defined in this table are used to identify the correct exchange and revaluation rates to be applied to each currency. Different rates are used in instances where specific currency markets exists. For example, financial and convertible markets or where pricing considerations require separate rates like normal market rates or notes or travellers cheque.

This table contains common elements of each currency. This table ensures that the same numeric codes and number of decimals are used for a currency across different companies in a multi-company environment.

HOLIDAY table is used to check whether the maturity or other schedule activity date is a working day at the time of entering a contract. It is possible to indicate the business day definition while entering the contract and Temenos Transact checks the scheduled activities and suitable overrides are generated.

HOLIDAY table is to indicate the public holidays for each country or region within the country. REGION and COUNTRY table must be defined before creating the HOLIDAY table.

The COUNTRY table contains static details of each country, the currency codes, etc.

Customer records are necessary to have details of the underlying party to the LC transactions, counterparty, correspondent banks and broker.

The banks need accounts for payment and receipt into customer and brokerage settlement accounts.